home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-cameron-tmux-00.txt < prev    next >
Text File  |  1993-08-05  |  13KB  |  382 lines
  1.  
  2.  
  3. Internet Draft                                           P. Cameron
  4.                                        Xylogics, International Ltd.
  5.                                                          D. Crocker
  6.                                              Silicon Graphics, Inc.
  7.                                                         August 1993
  8.  
  9.               Transport Multiplexing Protocol (TMux)
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet Draft.  Internet Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its
  15.    Areas, and its Working Groups.  Note that other groups may also
  16.    distribute working documents as Internet Drafts. Internet Drafts
  17.    are draft documents valid for a maximum of six months.
  18.    Internet Drafts may be updated, replaced, or obsoleted by other
  19.    documents at any time.  It is not appropriate to use Internet
  20.    Drafts as reference material or to cite them other than as a
  21.    "working draft" or "work in progress." Please check the I-D
  22.    abstract listing contained in each Internet Draft directory to
  23.    learn the current status of this or any other Internet Draft.
  24.  
  25.    It is intended that this document will be submitted to the IESG
  26.    for consideration as a standards document.  Distribution of this
  27.    document is unlimited.
  28.  
  29. Abstract
  30.  
  31.    One of the problems with the use of terminal servers is the
  32.    large number of small packets they can generate. Frequently,
  33.    most of these packets are destined for only one or two hosts.
  34.    TMux is a protocol which allows multiple short transport
  35.    segments, independent of application type, to be combined
  36.    between a server and host pair.
  37.  
  38. Acknowledgments
  39.  
  40.    This specification is the result of several discussions and
  41.    related initiatives through IETF working groups.
  42.  
  43.    (We have heard that Danny Cohen, of USC's ISI, suggested a
  44.    scheme like TMux about 8 years ago, but have not yet located the
  45.    reference.)
  46.  
  47. 1. Introduction
  48.  
  49.    When network designers consider which protocols generate the
  50.    most load, they naturally tend to consider protocols which
  51.    transfer large blocks of data (e.g. FTP, NFS).  What is often
  52.    not considered is the load generated by Telnet and Rlogin
  53.    because of the assumption that users type slowly and the packets
  54.    are very small.  This is a grave underestimation of the load on
  55.    networks and hosts which have many Telnet and Rlogin ports on
  56.    multiple terminal servers.
  57.  
  58.  
  59.  
  60. Cameron, Crocker        Expires: February 94               [Page 1]
  61.  
  62.  
  63.  
  64. Internet Draft                  TMux                    August 1993
  65.  
  66.  
  67.    The problem stems from the fact that the work a host must do to
  68.    process a 1-byte packet is very nearly as much as the work it
  69.    must do to process a 1500-byte packet.  That is, it is the
  70.    overhead of processing a packet which consumes a hosts
  71.    resources, not the processing of the data.
  72.  
  73.    If one assumes that most users connected to a terminal server
  74.    will be connecting to only a few hosts, then it should be
  75.    obvious that the network and host load could be greatly reduced
  76.    if traffic from multiple users, destined for the same host,
  77.    could be sent in the same packet.
  78.  
  79.    TMux is designed to improve network utilization and reduce the
  80.    interrupt load on hosts which conduct multiple sessions
  81.    involving many short packets.  It does this by multiplexing
  82.    transport traffic onto a single IP datagram, thereby resulting
  83.    in fewer, larger packets.  TMux is highly constrained in its
  84.    method of accomplishing this task, seeking simplicity rather
  85.    than sophistication.
  86.  
  87. 2. Protocol Design and Subconnection Messages
  88.  
  89.    IP hosts may engage in the use of TMux transparently, and may
  90.    even switch back and forth between use of TMux and carriage of
  91.    transport segments in the usual, independent IP datagrams.
  92.  
  93.    TMux operates by placing a set of transport segments into the
  94.    same IP datagram.  Each segment has a TMux mini-header which
  95.    specifies the segment length and the actual segment transport
  96.    protocol.  The receiving host demultiplexes the individual
  97.    transport segments and presents it to the transport layer as if
  98.    it had been received in the usual IP/transport packaging.  The
  99.    transport layer is, therefore, unaware of the special
  100.    encapsulation which was used.
  101.  
  102.    Hence, a TMux datagram appears as:
  103.  
  104.      | IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
  105.  
  106.    Where:
  107.  
  108.  
  109.    TM hdr         is a TMux mini-header and specifies the following
  110.                   Tport segment.
  111.  
  112.  
  113.    Tport segment  refers to the entire transport segment, including
  114.                   transport headers.
  115.  
  116. 2.1. IP Protocol field value
  117.  
  118.    TMux is indicated  in an IP datagram by the Protocol (ID) value
  119.    of XXXXX.
  120.  
  121.  
  122.  
  123.  
  124. Cameron, Crocker        Expires: February 94               [Page 2]
  125.  
  126.  
  127.  
  128. Internet Draft                  TMux                    August 1993
  129.  
  130.  
  131. 2.2. Header Format
  132.  
  133.    Each 4 octet TMux mini-header header has the following general
  134.    format:
  135.  
  136.                   | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
  137.                   +-------------------------------+
  138.                   |            Length             |
  139.                   +-------------------------------+
  140.                   |         Protocol ID           |
  141.                   +-------------------------------+
  142.                   |        Length check           |
  143.                   +-------------------------------+
  144.                   |          ID check             |
  145.                   +-------------------------------+
  146.                   |      Transport segment        |
  147.                   |       ...                     |
  148.                   |       ...                     |
  149.  
  150.    The LENGTH field specifies the byte count for the transport seg-
  151.    ment, from 0-255 octets.  For segments that are longer, individ-
  152.    ual datagrams should be sent.
  153.  
  154.    The Protocol ID field contains the value that would normally
  155.    have been placed in the IP header Protocol field.
  156.  
  157.    The two check fields are the 1's complement of the first two
  158.    fields (as a simple and quick to do checksum).  Thus if the
  159.    first two octets are treated as a single 16 bit value, the sec-
  160.    ond two octets treated as a 16 bit value will also be the 1's
  161.    complement of the first.  The transport segment associated with
  162.    the header is not checksummed, it is the responsibility of the
  163.    upper level protocol to check this.
  164.  
  165.    To ensure that TCP, UDP etc. segments keep their 32 bit align-
  166.    ment, where the segments being multiplexed is not a multiple of
  167.    32 bits long, extra octets will be added to re-align the end of
  168.    the segment, and hence the next segment.  These octets will be
  169.    zeroed on output and ignored on input.  This padding will not
  170.    effect the LENGTH field, it will still contain the real length
  171.    of the segment.
  172.  
  173. 2.3. Sending Data
  174.  
  175.    Host endpoints may choose to use TMux at any time and in either
  176.    (or both) directions.  They also may switch between use of TMux
  177.    packaging and the usual individual packets for individual trans-
  178.    port associations.  The only barrier to the use of TMux is for
  179.    the sender to know whether TMux is supported by the receiver,
  180.    which is important, since early use of TMux is likely to be lim-
  181.    ited.
  182.  
  183.    The easiest way to achieve this, is to only send TMux messages
  184.    to a host that has already sent you a TMux message.  This then
  185.  
  186.  
  187.  
  188. Cameron, Crocker        Expires: February 94               [Page 3]
  189.  
  190.  
  191.  
  192. Internet Draft                  TMux                    August 1993
  193.  
  194.  
  195.    leaves the problem of one host starting the TMux connection.
  196.    This is most easily accomplished by the host sending an IP data-
  197.    gram with no data, but with a Protocol field value for TMux.
  198.    This is referred to as a TMux ENQ message.  The host receiving
  199.    this message then knows that the originator supports TMux, and
  200.    can start to send TMux messages. This will in turn cause the
  201.    originator of the ENQ message to start to use TMux.  If for any
  202.    reason, the receiver does not intend to send TMux messages to
  203.    the originator, but is prepared to accept them, then it can
  204.    reply with another ENQ message.
  205.  
  206.    If an ENQ message does not get a response, then it is reasonable
  207.    to resend the ENQ a while later in case the message was lost.
  208.    If this again is lost, the ENQ may be repeated as often as
  209.    needed, but the time between requests should increase exponen-
  210.    tially.  Suitable times between ENQs would be 15 seconds, 30
  211.    seconds, 60 seconds, 120 seconds etc.
  212.  
  213.    Note that this checking process does not need to impede any of
  214.    the transport (user) data, which may be sent as convenient,
  215.    albeit in its less-efficient small-packet form.
  216.  
  217.    The only problem with this scheme, is that any host advertising
  218.    that it supports TMux, then stopping supporting it will cause
  219.    any other hosts a problem.  The solution to this, is to put a
  220.    Time To Live (TTL) value on a record of a host sending a TMux
  221.    packet, and expire them after a suitable time, eg. 1 hour.
  222.  
  223.  
  224. 3.  Protocol Behavior
  225.  
  226. 3.1. Transport Flow Control
  227.  
  228.    TMux operates as an extension to the IP datagram protocol.
  229.    Hence, it has no impact on most flow control mechanisms, since
  230.    they operate at the transport layer -- above TMux.
  231.  
  232.  
  233. 3.2. Connection Management
  234.  
  235.    The concept of a connection pertains to certain transport proto-
  236.    cols, but not to IP or to TMux.  Hence, when connection manage-
  237.    ment is required by a transport protocol using TMux, it occurs
  238.    in the same fashion as it does for IP.  In fact, the transport
  239.    protocol is not to be aware that TMux is being used.
  240.  
  241.  
  242. 3.3 Multiplexed Message Construction
  243.  
  244.    When a transport provider (eg. TCP or UDP) sends a packet, TMux
  245.    prepends that packet with a header to create a TMux message,
  246.    then appends the message to the Multiplexed Message under con-
  247.    struction.
  248.  
  249.  
  250.  
  251.  
  252. Cameron, Crocker        Expires: February 94               [Page 4]
  253.  
  254.  
  255.  
  256. Internet Draft                  TMux                    August 1993
  257.  
  258.  
  259.    When the first message to be transmitted is placed into the Mul-
  260.    tiplexed Message under construction, a timer is started.  When
  261.    the timer expires, all outstanding message are placed into the
  262.    Multiplexed Message and it is transmitted. This ensures that all
  263.    messages constructed before the timer expires are sent in a sin-
  264.    gle Multiplexed Message.  If during construction of the Multi-
  265.    plexed Message the buffer holding the packet fills, the Multi-
  266.    plexed Message is transmitted immediately.
  267.  
  268.    The delay time should be user configurable; a reasonable time is
  269.    20 to 30 milliseconds.  The time period wants to be large enough
  270.    to give a reasonable probability of sending multiple packets but
  271.    not so large that the echo response time becomes a problem.
  272.    This suggests that the upper limit for the timer is probably
  273.    1/10th second.  As the cost of using timeouts on many systems is
  274.    quite large it is recommended that a single timer is used and
  275.    that all connections are serviced on each expiry period.
  276.  
  277.    Additionally, configuration options may limit the number of
  278.    included data packets or the maximum size of the Multiplexed
  279.    Message before it is transmitted.  It is also suggested that
  280.    larger packets (eg those over 30 octets) should be sent as stan-
  281.    dard IP packets, and not multiplexed.  This is to ensure that
  282.    the delay used, does not put a delay on those packets for which
  283.    it is inadvisable.
  284.  
  285. 4. Security Considerations
  286.  
  287.    Because TMux is effectively an extension to IP, it does not have
  288.    any more impact on site security than does IP.  Security should
  289.    be dealt with by upper layer protocols.
  290.  
  291. 5. Author's  Addresses
  292.  
  293.    P. Cameron
  294.    Xylogics International, Ltd.
  295.    Featherstone Rd., Wolverton Mill
  296.    Milton Keynes MK12 5RD
  297.    United Kingdom
  298.  
  299.    Telephone:      +44  908 222112
  300.    Fax:            +44  908 222115
  301.    Email:          cameron@xylint.co.uk
  302.  
  303.    D. Crocker
  304.    Silicon Graphics, Inc.
  305.    2011 N. Shoreline Blvd.
  306.    P.O. Box 7311
  307.    Mountain View, CA 94039-7311
  308.    USA
  309.  
  310.    Telephone:      +1 415 390 1804
  311.    Fax:            +1 415 962 8404
  312.    Email:          dcrocker@sgi.com
  313.  
  314.  
  315.  
  316. Cameron, Crocker        Expires: February 94               [Page 5]
  317.  
  318.  
  319.  
  320. Internet Draft                  TMux                    August 1993
  321.  
  322.  
  323. 6. Discussion List
  324.  
  325.    There is a discussion list for this protocol, which for histori-
  326.    cal reasons is called:
  327.  
  328.            cmp-id@xylint.co.uk
  329.  
  330.    Request to join the list should be sent to:
  331.  
  332.            cmp-id-request@xylint.co.uk
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380. Cameron, Crocker        Expires: February 94               [Page 6]
  381.  
  382.